(12) INTERNATIONAL APPcRaTION PUBLISHED UNDER THE PATENT COOreRATION TREATY (PCT) 

(19) World Intellectual Property 
Oi^anization 
International Bureau 



(43) International Publication Date 
4 November 2004 (04.11.2004) PCT 




(10) International Publication Number 

wo 2004/095326 Al 



(51) International Patent Classification^: G06F 17/60, 

H04L 12724, 29/08. G06F 17/30 

(21) InternatioDal Application Number: 

PCT/FI2004/000254 

(22) International Filing Date: 23 April 2004 (23.04.2004) 

(25) Filing Language: English 

(26) Publication Language: English 



(30) Priority Data: 
03396036.0 



23 April 2003 (23.04.2003) EP 



(71) Applicant (for all designated States except US): COMP- 
TEL OYJ [FI/FI]; Ruoholahdenkatu 4, FI-00180 Helsinki 
(FI). 

(72) Inventor; and 

(75) Inventor/Applicant (for US only): ENQVIST, Juhana 
[FI/FI]; Merivalkama 8 D 41, H-02320 Espoo (FI). 

(74) Agent: SEPPO LAINE OY; Itamerenkatu 3 B, FI-00180 
Helsinki (FX). 



(81) Designated States (unless otherwise indicated, for every 
kind of national protection available): AE, AG, AL, AM, 
AT, AU, AZ, BA, BB. BG, BR, BW, BY, BZ, CA, CH, CN, 
CO, CR, CU, CZ, DE, DK, DM, DZ, EC, EE, EG, ES, FI, 
GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, KE, 
KG. KP, KR, KZ. LC, LK. LR, LS. LT. LU, LV. MA, MD, 
MG, MK, MN, MW, MX, MZ. NA. NT, NO, NZ, OM, PG, 
PH, PL, FT, RO, RU, SC, SD, SE, SG, SK, SL, SY, TJ, TM, 
TN, TR, TT, TZ, UA, UG. US, UZ, VC. VN, YU, ZA, ZM, 

zw. 

(84) Designated States (unless otherwise indicated, for e\'ery 
kind of regional protection available): ARIPO (BW, GH, 
GM, KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZM, ZW), 
Eurasian (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), Euro- 
pean (AT, BE, BG, CH, CY, CZ, DE, DK, EE, ES, H, FR, 
GB, GR, HU, m. IT, LU, MC, NL, PL, PT, RO, SE, SI, SK, 
TR), OAPI (BF, BJ, CF, CG, CI, CM. OA, GN, GQ, GW, 
ML, MR, NE, SN, TD, TG). 

Declarations under Rule 4.17: 

— as to applicant 's entitlement to apply for and he granted 
a patent (Rule 4A7(ii))for the following designations AE, 
AG, AL, AM, AT, AU, AZ BA, BB, BG, BR, BW. BY, BZ. 
CA, CH, CN, CO, CR, CU, CZ, DE, DK, DM, DZ, EC, EE, 

[ Continued on next page] 



(54) TiUe: A MEDIATION SYTEM AND METHOD WITH REAL TIME PROCESSING CAPABILITY 



Billing System 

CZ 



20 



Market Analysis 20 
&B1 



Network 20 
Monitoring 



interconnect, 20 
Fraud, DWH ... 



Mediation solution 

Analysis, Validation, Correlation. 
Enrichment, Formatting & E>elivery 



10 



OS 



Operator A's 
^Network 50 






Customer 


-\ 

's 


^Firewall 


Branch 






Office A 









customer's 
Branch 

■fin OHte«R 



o 



(57) Abstract: A mediation method and a mediation system divided into independent node components that process event records 
independently of the other components of the system. In addition, the system is provided with at least one node manager compo- 
nent that configures the node components and starts them up, when required. Further, the node manager component monitors the 
functioning of the node components and also stops the node components, if required. Each of the independent node components 
operates according to its own settings and is thus self-contained and capable of continuing operation even though some of the other 
components are temporarily inoperative. The system comprises also a system database that manages configuration information and 
stores audit trail data. 
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A MEDIATION SySTEH AND MHTHOD «ITH RBAL TIME 
PROCESSING CAPABILITY 
Technicfll FiAi^ 

The present invention relates to mediation! 

Mediation is a process wherein usage data is collected W , i 

and delivered to operator's Onln ^f'*'^ network 
^- ^ Operation and Business Support System (OSS/B99^ 

Mediation software collects usage data from network bv interf. • ^"^^^^^^S). 
network elements. TTie mediation layer then a. J^^T 

fomiats, and/or rates the data ! l^T ' ' ^"'^^^^^ 

o/or rates the data so that it is readable by the target OSS/Bq<5 

contains all the required infomiation. ^S^* OSS/BSS system and it 

Mediation software hides the complexity ofthe networks the OSS/BSS, . k 
ensuring that the data received by the OSS/BS^ . 

network elements the data is ^^sl^^ Z^^^^ 

This IS presented in Figure 1 . "ctworK elements. 

The pre^n, fevenSon relates also to .nediatioa me4«fc and systen^ fl« w . 
developed ^ view of ,^en.s ^ ^ JITerl^^r . 

-.-^e„.ed.a«oa Media«on soft^ -^^^^ ^ ^.^^ been jl . T 
«us being auo ease wi«. *e ^,0.., of ^ , .It 

ava^able . «.e ne^oHc Rea,-«„,e „edi.«o„ o<re. .oluuon , 

Backproiinrf Aff 

Traditional event mediation solution contains fimctionalities like collection 

data from network eleme^nt<. ^ collection .of usage 

eiworic elements, aggregation, conversion of data foimat to unifi^H ^ 
correlation, etc. This aU has been r..^ 4^ 

^^^^y ^ nsed for years 
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p^s managemeivt functionalities it provides etc. 

1 been evaluated ftom business point view: 

5 only very rarely event nicdiattcn — ^J^^ _ c»ate. what a« the new 
^« «uch money it can "^^Ili infonnation it can p«.auce for 

operators busmess processes (.e.g. t-u 

o „ot verv interesting as billing models where 
— •r:rr™rirJays^wn..sa.— tionwa^ J 

well known and well defined. 

A- *4o« i«; based on well-known sources of usage data, 
S.o.ysaid:.^.ion.^ev^ — and «.ative,y simple p.ocessin. 
— ^J^™t'^;!^Ln.edia.ionhas.eentoco«eCdata*o»the 
15 requirements. The mam purpose ev ^^^^ ^^^^^ 

network, convert it to busmess support system S> 
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, ^^.^ T^al-time event processing system. The 
n<i 6 449 618 discloses one real-tune ov^ ^ 
Pat^t p— US 6M« ^ ^^^^^^ ^ 3^^, 

modularity and no vendor independency. 

»• «on US 6 405 251 discloses another solution, which concentrates on W 
;r ~ -1 and use „. correlation and a^sation .hncUon. m IP 

networks. 

gisclosure_oOnYenti^ 

• rint, to create a reliable mediation system and method 
It is an object of the present mvention to create 

with real time processing capabiUty. 
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The object of the invention is achieved by dividing the mediation system in independent 
node components that process event records independently of the other components of 
the system. In addition, the system is provided with at least one node manager 
5 component that configures the node components and starts them up, when required. 
Further, the node manager component monitors the functioning of the node components 
and also stops the node components, if required. Each of the independent node 
components operates according to its own settings and is thus self-contained and 
capable of continuing operation even though some of the other components are 
10 tempoimily inoperative. The system comprises also a system database that manages 
configuration infomiation and stores audit trail data. 

The present invention allows a mediation method wherein event records from the 
generation layer of events caa be collected and processed substantially continuously as a 
stream. In the method, the processed event records can also be dehvered to an element 
15 of the operation system layer substantially continuously as a stream. 

According to the present invention, there is also provided a computer program product 
for running a mediation system, which computer program product comprises computer 
program means for controlling the operation of the node manager component(s) and the 
node components. 

20 The present invention makes it possible to construct a reliable mediation system and 
method with real time processing capability. The inventive concept allows also several 
usefiil and advantageous embodiments, which provide fiirther advantages. 

In an embodiment of flie invention, wherein the system is divided in self-contained 
nodes and data buffers have been provided between the nodes, there is no single-point 
25 of failure and the system is extremely reliable. 

An embodiment of the invention, wherein the node manager starts up new node 
components, when required, offers scalability to the mediation system. 

Invention offers also embodiments of a mediation system, which can be operated 
continuously once started, because all of the configurations can be made while the 
30 system in on production. 
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There are also embodiments, which allow both batch-type processing and real-time 
processing of event records. 

As is apparent from the above disclosure, the present invention can be applied in a great 
variety of applications requiring fast and reliable processing of event records. 

5 Brief Description of Drawings 

For a more complete understanding of the present invention and the advantages thereof, 
the invention is now described with the aid of the examples and with reference to the 
following drawings, in which: 

Figure 1 presents a block diagram of a mediation layer between the network elements 
1 0 and operations and business support systems. 

Figure 2 presents a block diagram of a single function in a framework according to an 
embodiment of the invention. 

Figure 3 presents a block diagram of a jframework according to an embodiment of the 
invention. 

15 Figure 4 presents a screenshot of an example of monitoring view of user interface 
according to an embodiment of the invention. 

Figure 5 presents a screenshot of another example of monitoring view of user interface 
according to an embodiment of the invention. 

Figure 6 presents a screenshot of another example of monitoring view of user interface 
20 according to an embodiment of the invention. 

Figure 7 presents a block diagram of an example of framework according to an 
embodiment of the invention. 

Figure 8 presents a block diagram of architecture according to an embodiment of the 
invention. 

25 Figure 9 presents a block diagram of another architecture according to an embodiment 
of the invention. 
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Figure 10 presents a block diagram of the main components of architecture according to 
an embodiment of the invention. 

Figure 11 presents a flow diagram of a process according to an embodiment of the 
invention. 

5 Figure 12 presents a flow diagram of another process according to an embodiment of 
the invention. 

Figure 13 presents a block diagram of audit coxmters and node functionality according 
to an embodiment of the invention. 

Figure 14 presents a block diagram of mxxltiplying a mediation process according to an 
10 embodiment of the invention. 

Figure 15 presents a block diagram of another multiplying a mediation process 
according to an embodiment of the invention. 

Definitions 

Event : Event is a transaction occurring in a telecommunications network. Events are 
typically caused by actions taken by a subscriber while using telecommimication 
services. Evens may also be based on actions taken by the telecommunication network 
or an apparatus connected to it, e.g. while executing telecommunications services. Some 
events may be even generated automatically while executing service programs and 
performing other functions for providing services to the customers. 

Event Record : Event Record is a record that indicates that an event has occurred. That 
is, an even record provides information that a subscriber has used a telecommunications 
service. Event record contains also detailed information about the event. Hence, an 
event record may contain information on the usage, e.g. if the used telecommunication 
service is a phone call, the event record may indicate how long the call lasted, or if the 
service is downloading a file from an FTP server, the event record may contain 
information about the size of the transferred data block. 

Real time : Real time refers to passing event record through mediation system in 
streaming format. That is, as soon as a certain node in mediation stream has processed 
(e.g. enriched) the record, it is passed to the next node. Pass-through time is a real-time 
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system may be, e.g. from about 1 millisecond to 10 seconds. In some embodiments, 
events may pass through the system even faster. Sometimes, depending on the 
embodiment and application, the term real-time may also comprise pass-through times 
longer that stated above. In general, a real-time service is a service that does not include 
5 considerable delays such that a user of the service considers acts being taken and 
services provided essentially at the moment the services are ordered (i.e. events supplied 
to the mediation system). 

Best Mode for Carrying Out the Invention 

Embodiment of the invention described below provides a nev^-generation mediation 
10 solution that has been especially designed for real-time handling of event record 
streams. Usage data flows through the mediation solution as individual event records, 
which are passed to billing, traffic engineering, network planning, balance management, 
fraud detection and/or other OSS/BSS systems. The OSS/BSS systems can be sure that 
their operations are based on accurate real-time information. 

15 The billing system receives event records from the mediation solution in an instantly 
billable form. The mediation solution allows various charging options; billing can be 
based for example on volimie, content value, QoS (Quality of Service) or time, or any 
combination of these. The mediation solution enables charging of content and MMS 
services (Multimedia Messaging Service) by being capable of transmitting usage data 

20 for example from MMSC (Multimedia Messaging Service Center), content proxies and 
application servers. It enables also usage-based billing of VPNs (Virtual Private 
Network) and Internet connections, allowing for example charging on the basis of QoS 
and bandwidth. 

Real-time information allows OSS/BSS systems to see in real-time what individual 
25 subscribers are doing and how the network is being used. This information can be 
analysed to find more competitive tariff structures and reduce customer chum. It can 
also help in depicting end-user characteristics and planning how to better serve 
individual customers. Functions such as balance management for customers' cost and 
credit control and fraud detection can use the information for controlling service usage. 

30 The mediation solution according to the embodiment has been designed to interface 
with any network and to serve any OSS/BSS system. It can be used for both packet and 
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circuit switched networks by all types of operators including 2G, 2.5G, 3G, IP, fixed- 
line and satellite network operators as well as service operators. It provides numerous 
off-the-shelf standard and proprietary interfaces to different OSS/BSS systems. The 
mediation solution can handle any type of records generated by different types of 
5 network elements. Furthermore, the embodiment can handle and process these records 
despite differences in their structure. 

If required, the presented embodiment can also handle batch-like file-based processing. 
Further, it is possible to schedule the executions of batch-based streams. The system 
can collect audit data per batch process. Batch processing coxild be emulated by 
10 triggering the first Node in the stream to start at configured times. All the other Nodes 
operate internally as always-on. 

Features and benefits of an embodiment 

In the following, arguments are presented for the profitability of a solution according to 
an embodiment of the invention, together with presentation of some of the novel 
15 features of the embodiment. 

Vendor independence — focus on performance and cost-efficiency 

With complex network and business support systems (in a multiswitch/system type of 
environment), it is beneficial to be able to make cost and performance comparisons 
between different players. The embodiment enables a vendor independent choice. 
20 Operators and service providers need to consider the performance and cost-efficiency. 
Due to these points, the mediation solution can be easily updated in a highly complex, 
multi-vendor environment. Adding new network element and OSS/BSS interfaces is 
fast, which allows rapid and cost-efficient launching of new services. 

Ability to create a best-of-breed. convertible customer care and billing system 

25 A mediation device according to the embodiment is truly iadependent from any network 
element and billing system vendor. The mediation solution is capable of collecting data 
from any network (3G, 2.5G, 2G, IP, fixed line or satellite) or service platform and of 
delivering it to any Operations or Business Support System - regardless of operators* or 
service providers* network or OSS/BSS vendor. 
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Hi gh performance 

In a typical configuration of the system, the event records are processed in a pipeline 
architecture, wherein all mediation functions are executed simultaneously for different 
records of the event record flow. This, combined with the core event record processing 
5 executed in programs written in a low-level programming language, ensures very high 
records per second throughput. 

Scalability and distributabilitv 

A mediation solution according to the embodiment is extendable from handling a small 
number of event records up to billions of events per day. Scalability can be reached 

10 simply by multiplying mediation processes (e.g. analysis, aggregation, rating) within the 
host. If the processing power of a single host is not sufficient, the mediation processes 
can be distributed to one or more additional hosts, in which case the system 
automatically takes care of transferring the event record data to the host it is next 
processed in. The hosts are typically UNIX, LINUX or suchlike efficient computers. 

1 5 Hosts fix>m different system vendors can be mixed without restrictions. 

Modular software - quick and reliable time-to-market 

The solution according to the embodiment consists of tested and proven modules. 
Operator's particular business solutions can be introduced in a quick and reliable 
manner. The mediation solution is a packaged software product that can be 
20 implemented in a considerably shorter time than tailor-made solutions. In addition to 
quicker implementation, an off-the-shelf product allows easier and more cost-efficient 
maintenance and usage. 

Easier management and monitoring of processing with large networks 

Prior art batch-based processing is very difficult to monitor with large networks. The 
25 solution according to the embodiment collects and stores all events and other data 
related to the mediation processes into a single, centralised storage, and allows a 
possibility to send them to e.g. a third party network management system. This allows 
easy, centralised management and monitoring of the system independently of the size of 
the network. 
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Reliability 

The mediation solution according to the embodiment has a straightforward architecture, 
which is based on well-proven technologies. The functional structure is based on totally 
new elements for processing events in an inventive enviromnent. The processes can 
5 function independently of each other and the managing system. All data is buffered in 
any kind of error and system overload situations. 

The system is designed so that there is no siagle point of failure, e.g. a conmion process 
for handling the event record transferring from one node to another. This means that as 
long as the host server is running, and there is free space in the host*s file system, the 
1 0 event record processing is not interrupted. 

Real-time network usage information 

A real-time mediation solution provides operators' and service providers' OSS/BSS 
systems with instant information about subscribers' current network usage. Real-time 
information is vital for many business operations such as network plaiming, traffic 
15 engineering, balance management and fraud detection. Further, having a real-time 
mediation solution offers various benefits to operators. Real-time usage information 
helps OSS/BSS systems to make operator business more profitable and increase 
customer satisfaction. It allows for example: 

- More accurate and timely billing cycles by allowing immediate creation of 
20 subscriber bills. 

- Balance management and fraud detection by offering real-time information 
about subscribers' network behaviour. 

- Capacity optimisation by giving instant information about network usage. 

- Verification of the quality of the network by giving the possibility for 
25 network monitoring. 

- In some cases, a real-time interface to the network is simply a necessity as an 
increasing number of network vendors are sliifting to support real-time 
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network elements. Some IP network elements require a real-time collection 
interface, since file-based collection from them is not always reasonable. 

- Flexible charging. 

With the mediation solution according to the embodiment, charging can be based on 
5 content value, QoS, volume, bandwidth or time, or any combination of these. The 
mediation solution enables billing of MMS and IP services by being capable of 
transmitting usage data for example from MMSC, content proxies, application servers 
and probes. The mediation solution can handle any type of records generated by 
different network elements independently of used record type. This so-called free record 
10 type handling is recognized and handled by configuration of the mediation solution 
described later in this document. 

Configurabilitv 

Users can define freely which processes to include in a mediation process chain. There 
can be several process chains (streams) fimctioning concurrently. Each process is fiiUy 
15 configurable, making it possible to define accurate rules for usage data handling. The 
order of the mediation processes is fiilly configurable and same processes can be 
- multiplied if needed. 

The configuration of the process chains can be done without disturbing the ongoing 
processing, and the user can decide when to activate the changes into the configuration. 
20 The version control of the configurations allows returning to an earlier working 
configuration version in case of problems. 

Easy operation 

In an embodiment of the invention having a web-based user interface, all monitoring, 
configuration and maintenance of the mediation solution can be done through the 
25 intuitive, web-based user interface. The mediation solution user interface offers web- 
based revenue assurance reports, which enable easy detection of gaps in usage 
information, as well as verification of the integrity of information flow. 

24/7 availabilitv and reliabilitv 
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The mediation solution according to the embodiment is a system with online 
configuration that is available 24/7. It is ready to receive event records fi-om the network 
any time. All mediation processes of the mediation solution, such as data analysis and 
correlation, run independently of each other. Even if one of the processes is atfected for 
5 example by a network error, all the other processes continue running as before. The 
mediation processes of the mediation solution run independently of the process 
management system. They can function temporarily without system critical resources, 
such as the system database. All data is automatically buffered in any kind of error 
situation to ensure that no event records are lost 

10 Functionality of an embodiment 

Mediation consists of different processes like collection, validation, enrichment, 
aggregation, correlation, rating, conversion and delivery. The varied functionality 
allows OSS/BSS systems to receive usage data just as they want it. 

Some of the main functions of a mediation solution according to an embodiment of the 
1 5 invention are described below. Each of these functions is configurable. 

Collection 

The mediation solution according to the embodiment is capable of interfacing with any 
network - e.g. 3G, 2.5G, 2G, IP, fixed line or satellite - or content and services platform 
- or any combination of presented network technologies. It collects the event records 
20 from the network as continuous real-time stream or as files. 

Validation and analvsis 

When receiving event records firom the network, the mediation solution checks them for 
duplicates and verifies their sequence. By doing this, it ensures that the numerous event 
records stream into the system in correct order and that none of them is missing or 
25 delayed or tries to enter the system for the second time. 

After collection, the mediation solution carefully examines and analyses the contents of 
the event records. It checks that all values included in the event record fields are 
applicable and in a correct format. It can join fields and insert additional values to them 
when necessary. 
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Enrichment 

The mediation solution according to the embodiment is able to enrich event records by 
completing them with information from external sources. It can, for example, fetch the 
infomiation on which customer category a specified service user belongs to, and add 
5 this information to the event record. Marking of customer category helps other 
processes such as billiag. 

Aggregation and correlation 

Li aggregation, the mediation solution according to the embodiment merges partial 
event records produced by a single service usage and coming from the same network 
10 source. • Aggregation thus allows the OSS/BSS systems to receive only one billable 
record from each service usage. 

Correlation involves combining event records also, but the records to be correlated 
come from different soxirces. A GPRS session, for example, produces S-CDRs (Call 
Detail Record) in SGSN and G-CDRs in GGSN that the mediation solution is able to 
1 5 correlate into one output record. 

The records to be correlated may come at the same time from access network and 
content platform, which is the case in a content usage session. The mediation solution 
then completes the event records from content platform with the user identification 
fetched from access network. The correlated records contain all the information needed 
20 for content charging: who the user was, what services he used and for how long, as well 
as the value of the services. 

Rating 

The rating functionality of the mediation solution according to the embodiment allows 
pricing of event records in the mediation system. Flexible rating criteria and various 
25 pricing models can be used as rating bases. Also subscriber specific rating is possible. 
The rated event records can be sent directly from the mediation solution to balance 
management and other applications without any intervention from billing system. 
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Storing 

All records of the mediation solution according to the embodiment can be stored into a 
long-term event database. The event records can be stored into the database during 
different mediation processes, for example before and after aggregation, correlation or 
5 rating. 

The long-term storage capability allows to view and fetch records from the database at 
all times and check how different mediation processes have modified them. The stored 
event data gives valuable information about subscribers' network usage in the long run. 

Formatting 

10 Before delivering the fully processed event records to the OSS/BSS systems, the 
mediation solution according to the embodiment converts them to formats compatible 
with these systems. The mediation solution is able to convert the records either to a 
standard format or to operators' proprietary formats. Due to conversion, an OSS/BSS 
system receives all usage information from the network in a uniform, predefined form. 

15 It should be noticed that the formatting of event records may be done also in any point 
or points through the processing chain (stream) of the mediation process. 

Delivery ..... 

The mediation solution according to the embodiment is able to simultaneously interface 
with multiple different OSS/BSS systems. Even if it performs all its collection and other 
20 processes in real-time, it is able to deliver the processed records to the OSS/BSS 
systenas either through a configured real-time protocol or a file interface. 

Architecture of a mediation solution according to an embodiment 

The keywords of the mediation, solution architecture are simplicity and 
straightforwardness. The modular design of the solution according to an embodiment of 
25 the invention enables real-time and distributable processes, reliable operation and high 
perforaiance. 

The mediation solution according to the embodiment consists of mediation processes, 
managers controlling the processes, system database and web-based user interface. 
Mediation processes such as collection, analysis, correlation and conversion are linked 
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together to construct processing streanis. Streams are fully customisable and there can 
be multiple streams simultaneously active. 

According to the embodiment, all processes are controlled by process managers, which 
start up, monitor, stop and configure them when so instructed. This is presented in 
5 Figure 3. Managers give configurations to the processes during start-up. Once started, 
the processes can function independently from the manager, also in case the manager is 
temporarily unavailable. 

Unlike the batch processing methods, which process the files in turns, the new 
architecture is an "always on" architecture, wherein, in the best case, all the processes 
10 are doing work simultaneously (pipeline architecture). 

A single functionality, like processing call data from all network elements and 
forwarding it to the billing system, is usually done in a single processing stream, unlike 
in the old mediation solution in which there is one batch processing method for each 
network element. 

15 Node (mediation process^ 

Nodes 120 are functional components specialised in different mediation processes, such 
as collection, aggregation, vaUdation, correlation and formatting, or a combination of 
these. Nodes are linked together to form processing streams for event record handling. 
Each stream 200 is fully configurable through the web user interface of the mediation 
20 solution according to the embodiment. 

Nodes 120 run independently of each other. This means that even if one of them is 
temporarily imavailable, the other nodes continue as before. This, in addition to their 
independence from the manager 1 10, adds to the reliability of the system. Also, any data 
that caimot be transferred from one node to another, due to for example a network 
25 failure, is buffered. 

Figure 2 presents the main idea of a node according to an embodiment of the invention. 
Some of the properties of a node are: 

- Totally independent of the controlling process, i.e. if the controller dies, the event 
record processing will continue. 
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- Always on: after the controller has started the process, it will not end until the 
controller stops it 

- Scans event records for processing from the source(s) designated by the controller. 

- Writes the output records to the destination(s) designated by the controller. 

5 - Writes revenue assurance etc. reporting data at regular intervals to a place 
designated by the controller 

- Sends heartbeat signal to the controller indicating that the node is alive. 

- Special nodes, like a collector node, can have following special attributes and 
features: 

10 ■ Timing of tiie sending of records for further processing: time-based 

intervals for streaming collectors for forwarding data in larger record 
blocks for improved throughput. 

■ Scheduling file-based collection or delivery process - the node itself 
handles the scheduling. 

15 Node Manager (process controller) 

While nodes take care of the actual processing of the event records. Node Manager 110 
makes sure they function in a controlled way. Node Manager 110 configures the nodes 
120 into correct processing order, starts them up, monitors and stops them when so 
ordered. Before starting up a new node 120, Node Manager 110 retrieves its 
20 configuration information firom flie system database 150 and configures the node 120, 
Since the node 120 itself contains the configuration, it is able to fimction properly even 
if Node Manager 110 and system database 150 are temporarily unavailable. 

Some of the properties and features of the Node Manager 110 are: 

- Self-contained process 



25 



For multi-host distribution, an identical Node Manager 110 process is installed and 
operated in each host. There is no master process for controlling Node Managers 
110. 
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- The Node Managers 110 know their responsibilities from reading the database 150; 
they do not know anything of each other and do not need to communicate between 
fliemselves. 

- Node Manager 110 starts and stops the processing streams 200 and nodes 120 
5 according to the orders read from the database 150. 

- It monitors the nodes 120 and restarts them in case of failure or lockup, 

- It reads the revenue assurance etc. reporting data files and saves it into the database 
150. 

- It automatically inserts file transferring processes when the processing crosses host 
10 boundaries. 

- It can optionally send any alarms with SNMP protocol to a configured network 
management system in case of problems in processing. 

System database 

System database 150 stores node configuration, audit trail information as well as status 
15 information of nodes 120, streams 200 and Node Managers 110. Also orders for Node 
Managers 110 are stored within the system database 150. 

Typically, the database 150 is viewed, updated and maintained with the user interface 
160 or the command line system tools, but external systems 170 can also connect to the 
mediation solution and access the system database 150. 

20 User interface 

The web-based user interface 160 of the solution is used for managing, configuring and 
monitoring of the system. The whole distributed system can be viewed and managed 
through this single-point interface. 

- Configuration of processing streams and nodes, configuration version management 
25 - Startup and shutdown of streams 200 and nodes 1 20 

- Monitoring of the Node Managers 110 and active streams 200 and nodes 120 
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- Revenue Assurance according to the stored reporting 

- Alarm management 

User functions in an embodim ent of t he invention 

The web user interface of the mediation solution according to an embodiment of the 
5 invention has been designed to make all monitoring and configuration operations fast 
and effortless. Below are presented some of its main user functions. 

Monitoring 

Figure 4 presents the main page of the user interface 160, which shows all the important 
information related to the event record streams 200 and mediation processes 200. The 
10 mediation process streams, their statuses and possible warnings, the numbers of 
collected event records and host-related information can be viewed. 

Monitoring is easy when all system and event information can be seen at a glance on the 
same web page. Possible gaps in event data can be detected fast and integrity of the 
event record flow can be easily verified. 

15 Configuration 

The main page contains links to different processes arid parts of the system that user 
may want to view in more detail. For example, user can click a link that takes him/her to 
view a particular mediation process stream. From fliere, he/she can take the process 
stream to a workspace and modify it or create a new version of it. A screenshot of 
20 configuring page is presented in jfigure 5. 

All process stream changes are versioned. This allows a user to backtrack a possible 
faulty configuration back to an earher, correctly working one, which can be used in 
production xmtil the problems with the new configuration are fixed. 

Online configuration of the mediation solution enables new versions of process streams 
25 to be taken into use seamlessly. The online configuration does not affect to other system 
processes, only to those particularly pointed system processes during configuration and 
activation of a process stream. 
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Audit trail 

The mediatioii solution according to the embodiment offers user a fiiU audit trail of all 
user operations. It allows user to see who has done what and when. User can see for 
example who has acknowledged and corrected a network error and when this has been 
5 done. 

Reporting 

The mediation solution according to the embodiment provides various reports and 
graphs related to event record streams and system functions. User can view for example 
the numbers of processed and rejected event records per network element and the peak 
1 0 hours of event record streams. This is presented in figure 6. 

An example of using an embodiment of the invention 
Figure 7 presents the following example- 
Starting point: Operator A 50 has a customer 60 that holds a video conferencing session 
between headquarters and two branch offices, which are located in different cities. The 
15 customer has built its network infrastructure so that it has IP- VPN using MPLS 
technology in its backbone network. The customer's firewall is connected to the 
operator A's edge network via an MPLS-enabled <bdge router. The traffic between the 
customer's firewall and corporate A's edge network is pure IP. 

The mediation solution 10 has been distributed so that it has real-time collection and 
20 aggregation functions near operator A's edge router 30 and a centralised processing 
module at operator A's data centre. Distribution is required since the router produces 
lots of information, which is minimised on site before sending it to the data centre over 
network. 

The customer's IP-VPN service offers three Classes-of-Service (CoS) for different 
25 applications with different QoS (Quality of Service) requirements: Platinum, Gold and 
Silver. Video conferencing has the highest QoS requirements; thus Platinum service is 
used. 



Operation: The mediation solution 10 collects usage information in a real-time stream 
fi*om operator A's edge router 30. The iirformation collected is flow information, firom 
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which the mediation solution 10 fetches different parameters such as user, application, 
router interface, CoS, used bandwidth and in-net/off-net traffic separation. 

The mediation solution according to the embodiment enriches the flow information to 
include time and date information and more detailed information for example about 
5 customer and QoS. The enriched information enables several usage-bjised billing 
models. In this case, the price is based on 

- the customer profile (discount to a valued customer), 

- CoS (Platinum service), 

- used bandwidth (only used in Platinum service), 
10 - in-net traffic (cheaper in your own network) and 

- time of day (cheaper outside office hours). 

In addition to the edge routers, the mediation solution retrieves network utilisation 
information from core routers. Operator A can use this information for network 
management purposes. 

15 The mediation solution according to the embodiment sends one aggregated, enriched 
and formatted IP Data Record (IPDR) to operator A's billing system. This record 
contains only the information needed for billing. A more detailed record is sent to the 
OSS/BSS systems 20 for storing more detailed information about service usage. This 
information is used for many purposes like SLA (Service Level Agreement) 

20 management, network planning, monitoring and fi-aud detection. 

Overview of an Initial Architecture according to an embodiment of the invention 

The initial architecture of the mediation solution according to an embodiment is 
described in Figures 8 and 9. The detailed requirements for tiie components are 
evaluated later in this docimient. 

25 The presented embodiment consists of the following separate parts: 

1. System Database 150 and User Interface 160 for centralised management of the 
system. 
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2. Node Manager 110 which controls chained data processing applications 140 within 
a host 100 

3. Node Base 130 which gives the basic functionality for various data processing 
applications 140 

5 4. Applications 140, which contain customized business logic for processing event 
records. 

Figure 8 illustrates the presented embodiment, the real-time processing architecture on 
high-level. The architecture consists of Node Maaagers 110 that control a number of 
Nodes 120 residing within the same physical host 100. The Node Manager(s) 1 10 have 
10 an interface to a System Database 150 that is used for storing various configuration and 
audit trail information. The User Interface also interfaces with the System Database. 
The solution uses file-based mterfaces for transferring usage data between the Nodes 
120 and for communication between the Nodes 120 and the Node Manager 110. 

Figure 9 illustrates the presented embodiment, the real-time processing architecture of 
15 several hosts on high level. In addition to figure 8, there are presented the Transport 
Nodes 121, which handle the transmission between the different hosts. 

The following high-level interfaces are identified within the system: 

D = data transmission and buffering mechanism 145 

C = configuration interface between Node Manager (process management system) and 
20 Nodes processes) 146 

A = audit data interface between Nodes and Node Manager for revenue assurance 
purposes 147 

M = management interface between Nodes and Node Manager 148 
API = application interfaces for integration and system maintenance 170 
25 DB = configuration, system monitoring and audit trail database 150 
UI = user interface 160 
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When the system is distributed to several hosts 100, each host has its own Node 
Manager 110 that controls the Nodes 120 within the host. Transport Nodes 121 take 
care of transferring data from one host to another. Figure 10 illustrates the distribution 
of the system. For clarification, flie hosts 100 can be situated in anywhere in the world. 
5 For instance, an operator may have several networks in different countries or even 
continents. In these cases it is recommended to set at least one host to each coimtry or 
continent. This minimizes the flow traffic over intercontinental transndssion lines and 
makes the system efficient and more reliable. 

Each Node 120 has standard functionaUty that provides automated data transmission 
10 mechanism between the Nodes and processing information logging mechanism between 
the Node and the Node Manager. The actual usage data processing logic is implemented 
by different applications 140 that reside in the Nodes. These applications 140 are 
isolated from internal data transmission mechanism and internal data formats enabling 
easier application development. Applications 140 are drawn as ovals in the figures 8-12 
15 presented. The system provides a standard interface through which the applications 
communicate with the processing framework. 

Terminology and Component Descriptions in the embodiment 

The initial terminology and the components of the mediation solution according to the 
embodiment are described in this chapter. Figure 10 illustrates the architecture of the 
20 mediation solution in more detail. Each component that needs to be named has its own 
number. The table 1 presents a name for each component and gives a short description 
of the component. 



Table 1, 





Name 


''Description 'r'^^'-'X h^'^, 


120 


Node 


Node is an independent processing module that consists of 
two parts: Node Application' and Node Base'. 

This component is always running when first started. 


130 


Node Base 


Node Base provides the basic standard functionality for the 
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Node. It handles the internal usage data transmission 
mechanism between the Nodes and encodes the intemal 

ii^ao'f* data TsFndp Rfi^ft nroviHes an interfacft fn flip T^ndp 

Application for accessing the usage data and collecting 
customised audit information. It also communicates with the 
Node Manager for exchanging management, audit and 
configuration information. 


131 


Node Input 


Node Input is responsible for reading Ihe data firom tiie 
intemal input data sources, parsing it and passing the data to 
Node Application interface. 

Node Input uses Data Transmission Interface that defines the 
intemal data format and data transmission mechanism. 


132 


Node Output 


Node Output is responsible for reading the data firom the 
Node Application Interface and encoding and writing it to 
Data Transmission Interface. 

Node Output uses Data Transmission Interface that defines 
the intemal data format and data transmission mechanism. 


133 


Node API 


Node API provides the Node Application the access to the 
usage data. It *hides* to intemal data transmission interface 
xrom me in one /vppucation. iNoae /\rx mciuues runcnonanLy 
for providing the usage data to and receiving it firom the 
Node Application. It is also used for retrieving customised 
audit information fi-om the Node Application and for 
providing configuration parameters to it. 


134 


Node 

Configuration 


Node Configuration is responsible for reading the 
configuration data firom the Configuration Interface and for 
initialising the Node according to given configuration 
parameters. Node Configuration also passes Node 
Application specific parameters to the Node API. 



) 
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Node Configuration uses Configuration Interface that 
defines the configuration data format and transmission 
mechanism. 




iNOuc /\uaix 


Node Audit is responsible for writing various audit data to 
the Audit Interface. Node Audit defines content for audit 
interface. 

Node Audit uses Audit Interface that defines the default 
audit data format and transmission mechanism. 

Node Audit uses also Management Interface that defines 
monitored data format and transmission mechanism. This is 
used for example for indicating the status of the Node. 


140 


Node 

Application 


Node Application is responsible for altering the usage data 
in reqxiired manner. This includes processing functions like 
altering the data, filtering die data, aggregating and 
correlating the data. Node Applications are easy to 
implement for any data processing purpose. 

The Node Base enables development of Node Applications 
for example in C, C++, Java or Perl.Node Application 
conamunicates with the Node Base for retrieving the usage 
data from the intemal data transmission mechanism or for 
sending usage data forward via the intemal data transmission 
mechanism. Node AppUcation also reports customised audit 
information about the usage data processing to the Node 
Base. 

If the Node is the first or the last Node in a Processing Chain 
the Node Application is also responsible for retrieving or 
sending the usage data from or to the required extemal 
interface. This includes encoding and decoding the usage 
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data. 


145 


Data 

Transmission 
Interface 


Defines the usage data format and data transmission 
mechanism between the Nodes. 


146 


Configuration 
Interface 


Defines the configuration data format and transmission 
mechanism firom the Node Manager to the Nodes. 


147 


Audit Interface 


Defines the audit data format and transmission mechanism 
from the Nodes to the Node Manager. 


148 


Management 
Interface 


Defines the Management Interface between the Nodes and 
the Node Manager. 


110 


Node 
Manager 


Node Manager is responsible for managing Nodes in the 
same host than it is running in. This includes starting up, 
shutting down, monitoring and configuring Nodes and 
collecting audit information from them. 




System 
Database 


System Database contains configuration information and 
audit trail data for all the Nodes and Node Managers in the 
system. Information in the System Database is also used for 
the User Interface. 


160 


User Interface 


User Interface is used for configuring, managing and 
monitoring the system. 


170 


Extemal 
Systems 


Interface that makes it possible to integrate different 
applications to the system: for example revenue assurance 
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Interfaces 


reporting tools etc. may consists of several different 
interfaces 


200 


Processing 

Chain 

(stream) 


Processing Chain consists of several Nodes. Typically a 
Processing Chain has Nodes for collection, processing and 
delivery. The number of Nodes is not limited. The number of 
Processing Chains in the system is not limited. 



Nodes 120 can be further categorised according to their functionality. The functionality 
depends on the Node Application 140 and the Node's position in the Processing Chain 
200. The first Node 120 in a Processing Chain 200 can be called a Collector Node and 
5 the last Node a Delivery Node. In these cases the data parsing and formatting 
functionality needs to be performed by the application 140 itself and the standard 
functionality provided by the Node Base 130 is not used. The flow of usage data and the 
standard components that become obsolete are shown in the Figure 1 1 . In this picture it 
is assumed that the data source 30 and destination 20 both operate with some real-time 
10 protocol, i.e. they are using a socket connection for sending and receiving data. 

If the output data destination 20 requires the use of file-based interface, the applications 
take care of formatting and writing the data in the output files. In case like this, it might 
be necessary to separate the output file generation and the delivery of the output files to 
separate Nodes 120. Then the Delivery Node only transfers the output data files to the 
15 destination via required protocol, for example ftp and does not parse the data at all. This 
is illustrated in Figure 12. 

Summary of the interfaces that are used between the system components: 
User Interface 160 - Svstem Database 150 

User Interface 160 retrieves information from the System Database 150 tables using 
20 table queries. System configurations and audit and status information are queried. User 
Interface also updates tables in the System Database upon user's request The updates 
consist of system configuration changes and management commands. 
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Node Managers) 110 - System Database 150 

Node Manager(s) 110 retrieve system configuration information firom the System 
Database 150. Node Managers 110 also downloads the configurations upon system 
start-up and re-configuration. Node Managers 110 also retrieve system software firom 
5 the System Database 150. Node Manager(s) 110 push the system audit and status 
infomiation to the System Database 150. This interface uses table updates and queries. 

Node Manager 1 10 - Nodefs^ 120 

ANode Manager 110 interfaces with the Nodes 120 residing in the same host 100. 

Node Manager 110 initiaUses a Node 120 by installing the Node software with the Node 
10 configuration 146. Node Manager starts and shuts down 148 the Nodes. Shutdown is 
executed by sending a signal. There are at least two different ways of shutting a Node 
down; immediate shutdown and shutdown after intemal record storage flush. 

Node Manager retrieves audit and status information 147 by collecting audit files 
genemted by a Node and evaluating the heartbeat file updated by the Node periodically. 

15 Node 120 -Node 120 

Nodes do not interface directly. The intemal data transmission within a Processing 
Chain 200 passes data from one Node to another. The data is passed in files. The files 
are self-descriptive: a file contains the data and the description of the data. A Node 120 
knows where to write ifs output data. The location of the output data is an input data 
20 source for the next Node(s) in chain. These locations are determined by the system 
configuration and are configured for the Nodes by the Node Manager(s) 110 

When two consecutive Nodes 120 in a Processing Chain 200 are located in the separate 
hosts 100, the intemal data transmission is executed by special Transport Nodes 121 
that are ioitialised, configured and started by the Node Managers 110 automatically. The 
25 actual transmission protocol may be for example ftp or if secure data transmission is 
needed scp. 
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Overview of a mediation solution according to an embodiment of the invention 

The functional features of the mediation solution according to an embodiment are listed 
below. 

The mediation solution consists of a User Interface 160, System Database 150, Node 
5 Manager(s) 110 and Nodes(s) 120. System Database 150 is used for storing the system 
configurations and various statistics reported by the system. The Nodes 120 perform the 
actual data processing and provide mfonnation about the processing via various 
counters. A Node Manager 110 manages all the Nodes 120 within a single host 100. 
Node Managers 110 collect the data processing information from the Nodes 120 and 
10 store it to the System Database 150. The User Interface 160 retrieves this information 
from the System Database 150 and generates various audit trail reports about the data 
processing. 

Nodes 120 are grouped into Process Streams 200. Each Node 120 belongs to a one 

Str^flm ^ f gtr ftam riO T iRi«t5; of at least one Nodft . D ata 15; passed in files from a 

15 Node to other. Each Node within a Process Stream constantly checks its input directory 
for new data files. When a file is detected, it is immediately processed. Files are 
processed one by one. A Node may produce multiple output files. If a Node is a 
Collector Node receiving data through a real-time interface (socket), it will write the 
data to the output file(s) that are closed periodically. Upon closing new data file(s) are 
20 opened. 

Therefore, the system will include the following components: 

— User Interface 160 

- System Database 150 

- Node Manager(s) 110 
25 - Node(s) 120 

— Extemal Systems Interface(s) 170 

User Interface 160 is used for monitoring, maintaining and configuring the system. User 
Interface interfaces with the System Database 150. 
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System Database 150 includes the system configuration information, system audit data 
and possibly the system software for the Nodes 120. 

Node Managers 1 10 are installed to each host 100 and they will manage the Nodes 120 
within a host 100. Node Manager interfaces with the System Database 150. Node 
5 Manager 110 collects configuration information (and possibly the Node software) from 
the System Database, configures 146 the Nodes and starts them up. Node Manager(s) 
also collect audit and status information 147 firom the Nodes and deUvers the 
information to the System Database. Node Managers also send Node status information 
to the Network Management System (NMS). 

10 Nodes 120 will process the usage data. A Node consists of basic functionality in Node 
Base 130 used for transferring data between the Nodes in system internal format and 
Node Application 140 that performs the actual usage data processing. 

External Systems Interface(s) 170 are connections to the System Database 150, which 
can be used for integrating extemal system such as management systems or reporting 
15 tools with the product. Extemal Systems Interface is a general name for the interface 
and it may be divided to several extemal apphcation specific interfaces. Some of the 
identified Extemal Systems Interfaces and possible applications attached to them are 
described below: 

- Management Interface offers a monitoring and management interface for Network 
20 Management Systems (NMS) via SNMP. NMS could request status and statistical 

and other audit information that is then retrieved firom the System Database. NMS 
could also manage the system: start-up, restart and shutdown Nodes or Processing 
Chains and change configurations 

- Reporting Interface provides an interface to audit and status iaformation in the 
25 System Database. A Reporting Tool can then provide various reports based on this 

data. 

System Operation and Data Processing Principles in an embodiment 



The system configuration is stored and maintained in the System Database 150. There is 
one Node Manager 110 installed in each host 100 and started as an independent process. 
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The configurations are changed from the User Interface 160. The system is managed 
from the User Interface. 

Upon the system start-up. Node Managers 110 read the Processing Chain configurations 
from the system database 150 and starts up the Processing Chains. A Processing Chain 
5 200 consists of Nodes. Each of the system components executes independently once 
started. The Processing Chains 200 process the data until they are shut down. The Node 
Manager 110 shuts down the Processing Chains 200 or Nodes 120 upon user's request. 

The usage data flows between the Nodes 120 in internal data files. Each Node checks 
its' input data sources constantly for new data files. When a new data file is detected, it 
10 is immediately processed and delivered to the output destinations. Usage data is 
processed file by file. When an input file is processed and the possible corresponding 
output data file is created, the input file is removed. This way no data is lost if a Node 
120 crashes during data processing. Each Node locks the input file it is reading. This 
way no other Node can erroneously read the same file. 

15 At a crash recovery the Node will start writing to the beginning of the existing 
temporary file. This ensures that no duplicate records are generated and no temporary 
files are lefl; permanently on disk. 

If a Processing Chain 200 is distributed to several hosts 100, the system will 
automatically take care of usage data transmission between hosts. This is done by an 
20 application 121 that is divided into the sender and receiver processes, which reside in 
the separate hosts. 

There is a mechanism for discarding usage data that is identified to be invalid by the 
usage data processing logic. It is possible to feed the invalid xxsage data back to the data 
processing chain. The invalid data is formatted similarly as it arrived to the Node that 
25 discarded it. 

System Momtoring according to an embodiment 

The Node Manager 110 constantly monitors the status of the nodes, and: 
- If a Node has crashed the Node Manager will start it up again 



- If a Node has frozen the Node Manager will kill and restart it 
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Restarting is tried a few times. If the first restart does not succeed, the current block of 
input records for the Node is discarded as faulty data to a storage directory, and the 
processing continues from the next record block in the queue. 

Node Managers can send SNMP traps to inform Network Management System about 
5 the statuses of the Nodes and other problems such as low disk space, database and 
network coimection trouble. The status information is also stored to the System 
Database from where the information is collected and shown in the User Interface. 

System Aud it Inform ation accordiiijg to an embodiment 

Usually mediation comprises many tasks such as aggregation, correlation and fQtering. 

10 Sometimes records are rejected, omitted and in some cases even new records are 
created This leads to a situation where the number of records input to the mediation 
solution does not equal the records output from the mediation solution. This requires 
that mediation solution offers transparency so that the users of the system may monitor 
the niraiber of incoming and outgoing records and confirm that all records are properly 

1 5 processed by tiie mediation solution. 

The nodes report to node manager 1 10 by providing certain audit counters. These audit 
covmters include important counters, that is, those counters that every node application 
must report to the node manager after certain periods. These important counters are 
listed in table 2. 

20 Important coxmters are used to calculate that there is no naismatch in the counters and 
thus ensuring providing evidence to the user of the system that mediation solution 
hasn't lost records. 

Example: 

Data through a Node or a Processing Chain: Output records = input records + records 
25 residing witiiin the Nodes at start + split records + duplicated records + generated 
records - filtered records - discarded records - records aggregated/correlated - records 
residing in the Nodes at the end. "At start" and "at end" refer to at the end and start of a 
certain configured time period, for example 5 minutes that is under investigation. Every 
node has a certain reporting period and in the end of the period all the counters are 
30 reported by the node 120 to the node manager 110. For example, as a default a Node 
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reports audit information per input data file when the input data file is processed. If the 
input interface is a real-time interface (the interface is firom e.g. a network element and 
not from a preceding node), the audit information is reported when the output data files 
are closed. If more than one ou^ut data files are generated, all the files are closed at the 
5 same time. If both of tiie interfaces are real-time interfaces, then the audit information is 
reported periodically based on time. If there is no "standard" input interface, i.e. the 
Node flushes its intemal data storages or Node reprocesses rejected data; the audit 
inforaiation is reported when the corresponding output data files are closed; 

Each Node 120 has one input source and zero or more output destinations per reporting 
10 period. The audit information can be divided into three categories (types): information 
about the input interface, information about the Node's intemal fimctionality and 
information about the output interfaces. The audit information is provided by these 
categories. If a Node has more than one output interface, the audit information should 
be provided for each output interface separately. For one reporting period each Node 
15 reports the input file (if used) and the output interface information per produced output 
file (if any produced). 

The usage of the counters related to Node fimctionality is described in the Figure 13. 

The important counters listed in Table 2 can be fiirther divided to sub counters, e.g. 
covmter "rejected'' may consist of lower level counters "rejected for reason x" and 

20 "rejected for reason y". In addition to important counters, nodes can provide other 
coimters containing information that are customer specific. These counters are defioied 
in customer specific logic and according to this information it is possible to build also 
customized reports. These customised reports can provide information for example 
about different kind of statistics of processed records, graphs showing the trend of 

25 rejected records or durations etc. 



Table 2. 



Counter 


Explanation 


Type : 


Records in 


The number of records received firom input 
source(s). 


Input interface 
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Counter 




Type-"-.-. • 


In reprocess 


The number of previoxisly rejected records 
received for reprocessing. 


Input interface 


Stored 


The number of records that are "held within the 
node''. Meaning, records that will be aggregated 
nr rorrelfitefi with other records that have not vet 
been received. In calculations defining that there 
are no mismatches in covmter values, it is 
actuaUy the change of this value within a time 
period that is interesting. 


Intemal 


Omitted 


The number of Filtered records. These records 
are filtered according to the customised rules. 


Intemal 


Rejected 


The number of records that are rejected for a 
reason or another. 


Intemal 


Expired 


The number of records that have expired. E.g. a 
correlated record that has been "stored " has later 
expired according to a time stamp. 


Intemal 


Split 


The number of records spUt, that is, one record 
has been split to two or more. Criteria for 
spUtting are defined by customised rules. 


Intemal 


Duplicated 


The number of records duplicate, that is, one 
record has been sent further as two or more 
copies. 


Intemal 


Generated 


The number of new generated records. 
Customised rules may define that in some cases 
new records are generated. A common case 
would be e.g. writing header and trailer records. 


Internal 
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Counter 




Type 


New partials 


This is related to Stored and in reprocess 
counters. New partials are the records that are 
sent to correlation or aggregation process. 


Internal 


Merged 


The number of records merged. 


Internal 


Completed 


The nxmiber of records that have been output 
because aggregation or correlation process has 
been completed. 


Internal 


Flushed 


The number of records that were flushed out 
from correlation or aggregation process. 


Internal 


Out 


The number of records output. 


Output 
interface 



Nodes 120 residing at the edges of a Process Stream 200, i.e. Collector and Delivery 
Nodes read and^or write data to and from external systems without using the internal 
transmission mechanism. This interface may be file-based where records are transferred 
5 witlrni data files or socket-based where the records are transferred through some real- 
time protocol. 

For socket-based interface the number of bytes transferred (in and out) and the number 
of bytes rejected due invaUd format and parsing errors should be reported. For file- 
based interface the names of the files transferred (in and out), their sizes (in and out) 
10 and the number of bytes rejected due invalid format and parsing errors should be 
reported. These additional counters are listed in table 3. 
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Table 3. 



Audit Counter 


' Expfanation- • ^V- ' fy' • J 




Bytesin 


The number of bytes in through a socket 
interface. 


Input interface 


Filein 


The input file name and the size in bytes. 


Input interface 


BytesRejecte 
d 


The number of bytes rejected due invalid 
format 


Input interface 


BytesOut 


The number of bytes out through a socket 
interfece 


Output interface 


FileOut 


The output file name and the size in bytes. 


Input interface 


Node Applications according to an embodiment of the invention 



3 W) 



Different types of Node AppUcations 140 that are responsible of the usage data 
5 processing are listed in this chapter. Some of the Node Applications are conamon for 

most of the product installations and some are customer specific. — , 

Data Collection & Data Parsing (Input Interfaces^ 

Collector Nodes collect usage data either as files or through a real-time protocol. There 
are generic Collectors and Network Element specific Collectors. 

1 0 Collector Nodes parse the usage data collected. It is be possible to define rules how data 
is parsed in the application configuration. A typical Collector converts the usage data 
into internal format for the next Node in the Processing Chain. It is also possible that the 
Collector Node is the only Node in the Processing Chain; in this case the Node collects, 
parses, processes and delivers the usage data. An example of this is a Node that acts as a 

1 5 protocol converter. 
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Data Processing 

The standard data processing functionality includes: 

- Data validation and filtering 

- Data manipulation and splitting 
5 - Data duplication 

- Data generation (for example header/trailer records) 

- Lookup mechanism for receiving information from external sources 

- Data Aggregation / Correlation 

- Record duplicate/sequence checking 

10 When the Node Application operates based on the internal data format, no data parsing 
and formatting functionality is needed. The Node Application receives data record by 
record from the internal data transmission mechanism. 

Correlation may use external record storage for intermediate records. The correlation 
function is able to read records from multiple sources. 

1 5 Data Delivery and Data Encoding (Output Interfaces) 

Delivery Nodes deUver usage data either as files or through a real-time protocol record 
per record. There are generic Delivery Nodes and Btisiness Support System specific 
Delivery Nodes. 

The Delivery Nodes encode the data to the format the interfaced OSS/BSS requires* For 
20 file-based delivery, file-naming fimctionality is available. In case of file/batch type 
delivery, it is possible to schedule the delivery application. 

Increasing throughput by multiplying mediation processes according to an 
embodiment of the invention 

In case of insufficient processing capacity of a mediation function or functions within a 
25 processing stream, an embodiment starts up an identical copy of the node in question to 
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scale up the processing capacity of the system. Figure 14 shows an example, in which 
the node 2 has insufficient performance in scenario A. In scenario B, the node 2 has 
heen dupUcated to run in nodes 2a and 2b, which are running in parallel and sharing 
workload between them. Because the embodiment uses buffers between the consecutive 
5 nodes, the parallel nodes 2a and 2b can use the same buffers from which to read event 
records and to which to write. In such an arrangement, the preceding node 1 need not be 
modified when duplication node 2 as node 1 can continue writing its output to the one 
and same buffer. In a corresponding manner, node 3 can read from the same buffer 
regardless of the number of nodes 2 that write to the buffer. 

10 If the processing capacity of a single host is the bottleneck, the sharing of the workload 
can be done between hosts. Figure 15 describes an embodiment, which is able to 
enhance processing capacity of the system in this way. In Figure 15, nodes 2 and 3 have 
been multiplied into nodes 2a, 2b, 3a and 3b running in one host, and nodes 2c, 2d, 3c, 
3d naming ia another host, all processing the event records in parallel. 

15 Buffers are placed between the nodes to ensure the reliability of the mediation process. 
Reliability measures with the buffers include a certain processing order of event records 
within the node, outgoing bujffer and incomiug buffer. In a preferred embodiment, event 
records are stored within the buffers as groups. Number of records in each group can 
dynamically vary during runtime from one record to any number of records, as long as 

20 there is free storage space available. Event records are not deleted from incon^bag buffer 
before the node has processed all information relating to a record group, and has written 
the processed event records to outgoing buffer, thus ensuring data integrity in failure 
situations. In case of multiplied mediation process where one incoming buffer feeds 
several nodes, the first node available for process takes the first available event record 

25 group for processing. The system is provided with a locking mechanism to ensure that 
each event record is processed only by one of the multiplied nodes. When a node takes 
an event record group for processing, the node marks (locks) the event record group 
with "under processing" status. Hence, the other nodes know that the particular group is 
reserved for another node and they can take the next one form the buffer for processing. 

30 As already described above, the processing node removes the copies of the event 
records in a group from the inconMng buffer only after processing and successfully 
writing the processed event records into the outgoing buffer. Thus, no data is lost in 
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case the processing node shuts down in an uncontrolled way due to failure of the node 
or external system, and the lock of the input event record group is automatically 
released by the underlying UNIX operating system. When the node recovers, it removes 
any incomplete record groups in output buffer(s) and restarts processing from the start 
of the input record group. In case of multiple nodes reading from the same input buffer, 
another node will take care of processing the interrupted input record group as soon as it 
is unlocked. 

Buffers also guarantee that in case the system or a part of it breaks down, the whole 
mediation process need not to be started from beginning. Instead, the process can 
continue from flie point wherein the break down happened. The system keeps an audit 
trail of records read and written by each node to ascertain that no records are lost or 
duplicated, even if failure occurs. 

The above description is only to exemplify the invention and is not iutended to limit the 
scope of protection offered by the claims. The claims are also iutended to cover the 
equivalents thereof and not to be construed literally. 
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Claims: 

1. A method for mediating event records between a generation layer of events and an 
operation system layer of events in a commmiications network by means of a mediation 
layer of events, which includes at least one first self-contained component of the 
5 mediation layer and at least one second self-contained component of the mediation 
layer, which operates independently of each first component of the mediation layer, and 
at least one buffer, the method comprising 

- collecting event records firom an element of the generation layer of events 
substantially continuously as a stream, by the at least one first self-contained 

1 0 component of the mediation layer, 

- processing the collected event records substantially continuously, wherein the step 
of processing includes: 

- writing the output firom each of the at least one first self-contained component 
into one of said at least one buffer, and 

15 - reading the input for each of the at least one second self-contained component 

firom one of said at least one buffer, 

- delivering the processed event records to an element of the operation system layer 
of events substantially continuously as a stream, by the at least one second self- 
contained component of the mediation layer. 

20 2. A method according to claim 1, wherein at least part of the step of processing event 
records is performed by at least one first self-contained component of the mediation 
layer. 

3. A method accordrug to claim 1 or 2, wherein at least part of the step of processing 
event records is performed by at least one second self-contained component of the 

25 mediation layer. 

4. A method according to any of claims 1 to 3, wherein at least part of the step of 
processing event records is performed by at least one third self-contained component of 
the mediation layer that operates independently of the other self-contained components 
of the mediation layer. 
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5. A method according to any of claims 1 to 4, wherein at least two different hosts are 
used such that at least one of the self-contained components of the mediation layer runs 
in a first host and at least one of the other self-contained components runs in another 
host 

5 6. A method according to claim 4, comprising the steps of 

- delivering event records from each of the first self-contained components of the 
mediation layer to the at least one third self-contained component of the mediation 
layer via at least one buffer, and 

- delivering event records firom the third self-contained components of the mediation 
10 layer to one of the at least one second self-contained component of the mediation 

layer via at least one buffer. 

7. A method according to any of claims 1 to 6, wherein the event records are passed 
through at least three self-contained components of the mediation layer, starting fi^om 
one of the first self-contained components, then through at least one third self-contained 

1 5 component and finally through one of the second self-contained components. 

8. A method according to claim 7, wherein the step of delivering event records 
comprises 

- writing the event records output by a preceding self-contained component of the 
mediation layer into a buffer, and 

20 - reading the buffer substantially continuously by the subsequent self-contained 
component of the mediation layer. 

9. A method according to claim 8, wherein the preceding self-contained component of 
the mediation layer outputs event records into the buffer one by one, and the subsequent 
self-contained component of the mediation layer reads event records firom the buffer one 

25 by one. 

10. A method according to claim 8, wherein the preceding self-contained component of 
the mediation layer outputs event records into the buffer grouped into small groups of 
event records, and the subsequent self-contained component of the mediation layer 
reads event records from the buffer in small groups of event records. 
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11. A method according to any of claims 8 to 10, wherein at least two separate self- 
contained components of the mediation layer write event records into the same one 
bufifer. 

12. A method according to any of claims 8 to 11, wherein at least two separate self- 
5 contained components of the mediation layer read event records from one and the same 

buffer. 

13. A method according to any of claims 8 to 12, wherein after reading an event record 
from a buffer, a copy of the event record is retained in the buffer, and removed from the 
buffer only after successfiilly outputting the event record from the reading self- 

1 0 contained component of the mediation layer, 

14. A method according to claim 13, wherein the retained event record is mark with 
status information indicating the "imder processing" status of the event record. 

15. A method according to any of claims 1-14, comprising the steps of monitoring by a 
monitoring system the operation of the self-contained components of the mediation 

15 layer and, in case of failure of any of the self-contained components, automatically 
setting up a new self-contained component to replace the failed component. 

16. A method according to any of claims 1-15, comprising the steps of monitoring by a 
monitoring system the production capacity of the self-contained components of the 
mediation layer and, in case of insufficient production capacity of any of the self- 

20 contained components, automatically setting up an auxiliary self-contained component 
parallel to the self-contained component with insufficient production capacity. 

17. A method according to any of claims 1-16, wherein the auxiliary self-contained 
component is set up to run in a host different to the host in which the self-contained 
component with insufficient production capacity runs. 

25 1 8. A method according to any of claims 1-16, comjirising the steps of 

- receiving event records from the step of collecting in a source system format, 

— converting the received event records into a mediation layer format. 
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- supplying the collected event records to the step of processing in the mediation 
layer format, 

- receiving the processed event records from the step of processing in the mediation 
layer format, 

5 - converting the processed event records into an operation system layer format, and 

- supplying the processed event records to the step of delivering in the operation 
system layer format. 

19. A method according to any of claims 1 - 18, wherein the step of processing event 
records comprises at least one of the following: vahdating and analysing event records, 

10 enrichment of event records, aggregation and correlation of event records, formatting of 
event records and rating. 

20. A method according to any of claims 1-19, wherein each of the self-contained 
components operates independently and continuously once started. 

21. A method according to any of claims 1 to 20, comprising the steps of 

15 - stopping the operation of a self-contained component by the self-contained 
component itself, and 

- performing said step of stopping the operation by the self-contained component 
only if instructed so by a manager component of the mediation layer. 

22. A method according to any of claims 1-21, comprising the steps' of 

20 - providing each of the self-contained components with its own individual settings, 
and 

- each of the self-contained components functioning according to its own individual 
settings. 

23. A method according to claim 22, wherein said individual settings of each of the self- 
25 contained components include 
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— a node base part of the settings, which is identical to the node base parts of the other 
self-contained components within the mediation layer, and 

— a node application part of the settings, which contain custom processing rules and 
which is different to the node apphcation parts of at least most of the other self- 
contained components within the mediation layer. 

24. A system for handling event records in a communications network between a 
generation layer of events and an operation system layer of events, the system 
comprising: 

— at least two independent node components for processing event records, each of the 
independent node components having its own settings according to which the node 
operates independently of other components of the system, at least two of the 
independent node components being configured to handle event records in series 
such that the first independent node component outputs into a buffer and the second 
independent node component reads its input from the buffer, 

— at least one node manager component for configuring the node components, starting 
up the node components, monitoring the fimctioning of the node components and 
stopping the node components, when required, and 

— a system database for managing all configuration information of each component 
and for storing information on handled events. 

25. A system according to claim 24, wherein more than one independent node 
component have been configured to output into the same buffer. 

26. A system according to claim 24 or 25, wherein more than one independent node 
component have been configured to read its input from the same buffer. 

27. A system according to any of claims 24 to 26, wherein at least two of the 
indepradent node components have been configured to input, process and output event 
records substantially continuously. 

28. A system according to any of claims 24 to 27, comprising a user interface for 
controlling, monitoring and configuring the system. 
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29. A system according to any of claims 24 to 28, wherein the configuration or settings 
of any component can be changed by a supervisor at any time, without stopping the 
handling process. 

30. A system accordiag to any of claims 24 to 29, wherein the tasks undertaken by the 
5 node components include collecting events records from a communication network, 

aggregatiag event records, converting event records, analysing event records, 
correlattQg event records, enriching event records, formatting event records, rating 
events and/or delivering event records. 

31. A system according to any of claims 24 to 30, which is configxired to process event 
10 records in several, simultaneously operating, and at least partly parallel streams. 

32. A system according to any of claims 24 to 31, comprising at least two audit trail 
comiters for counting auditing values, such as number of: incoming records, rejected 
records, reprocessed records, records residing in a specific node component, records 
omitted due to filtering, records expired or deleted, new records created due to splitting 

15 or duplication, new records generated that are not related to input records, input records 
sent to aggregation/correlation process, records that were merged due to aggregation or 
correlation, resulting records that were completed and came out from the 
aggregation/correlation process, resulting records that were flushed out from the 
aggregation/correlation process, records left to a specific node component and/or 

20 records written out. 

33. A system according to any of claims 24 to 32, comprising at least one audit trail 
ftinction for checking that no data is lost within the system. 

34. A system according to any of claims 24 to 33, comprising at least one data storage 
component, wherein at least one node component is configured to write information on 

25 all of the events processed by the node component, 

35. A system according to any of claims 24 to 34, wherein the node manager component 
is configured to start up a new node component in case a node component in the system 
fails such that the new node component replaces the fimction of the failed component in 
the processing chain. 
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36. A system according to any of claims 24 to 35, wherein the node manager component 
is configured to start up a new node component parallel to a functioning node 
component in case the processing capacity of the system has to be raised. 

37. A system according to any of claims 24 to 36, wherein each of the node components 
5 comprise a node base providing basic functionaUty of the node component and an 

appUcation containing processing rules, according to which the node component 
processes the event records input to the node component. 

38. A system according to claim 37, wherein the node bases of the node components are 
identical to each other. 

10 39. A system according to claim 37 or 38, wherein the node base includes an input 
module, an output module, an API module, a configuration module and an audit 
module. 

40. A system according to aay of claims 24 to 39, wherein the node components have 
been configured to continue their independent operation until instructed otherwise by 

15 the node manager component. 

41. A system according to any of claims 24 to 40, comprising at least two separate 
hosts, each of the hosts running at least one of the independent node components. 

42. A computer program product for a system for handling event records in a 
communications network between a generation layer of events and an operation system 

20 layer of events, which system comprises independent nodes for processing event 
records, the computer program product comprising: 

- a node base program means capable of providing basic software functionality for an 
independent node, said basic software functionality including an external interface 
of the node and an internal interface of the node. 



25 



- an application programming interface means for receiving application programs for 
independent nodes, which appUcation programs are capable of interfacing with the 
intemal interfaces of the node components. 
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- a node manager program means for setting up at least one node manager that is 
capable of constmcting, configuring, starting up, monitoring and stopping the 

' independent nodes, and 

- a user interface program means for setting up a user interface for configuring the at 
5 least one node manager. 

43. A computer program product according to claim 42, wherein the node manager 
program means include program code means to direct a node manager to construct 
independent nodes by combining a copy of node base program means and an 
application program. 

10 44. A computer program product according to claim 42 or 43, wherein the application 
program contains logical rules according to which the node processes the event records 
input to the node. 

45. A computer program product according to any of claims 42 to 44, wherein the 
extemal interface of the node enables the node to communicate with other nodes and the 

1 5 node manager. 

46. A computer program product according to any of claims 42 to 45, wherein the node 
manager program means include program code means to direct a node manager, in case 
a node in the system fails, to construct, configure and start up a new node that replaces 
the fimction of the failed node. 

20 47. A computer program product according to any of claims 42 to 46, wherein the node 
manager program means include program code means to direct a node manager, in case 
of insufficient production capacity of any of the nodes, to construct, configure and start 
up a new node parallel to the node with insufficient production capacity. 

48. A computer program product according to any of claims 42 to 47, wherein the 
25 application programming interface means are capable of supporting several 

programming languages. 

49. A computer program product according to any of claims 42 to 48, which is capable 
of configuring the nodes to form processing chains of serially connected independent 
nodes, for processing the event records. 
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50. A computer program product according to claim 49, which is capable of configuring 
the nodes in the processing chains to transfer event records from the preceding node in 
the chain to the subsequent node in the chain by means of a buffer. 

51. A computer program product according to any of claims 42 to 50, which is capable 
of configuring the nodes to function continuously and independently until instructed 
otherwise by the node manager. 

52. A computer program product according to any of claims 42 to 51, which supports 
multi-host execution and is capable starting up nodes in different hosts, and configuring 
the nodes in different hosts to form processing chains for processing the event records. 
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